home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group98a.txt
/
000175_icon-group-sender _Thu Apr 23 08:55:57 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
3KB
Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id IAA28064
for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Thu, 23 Apr 1998 08:55:57 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
id AA04922; Thu, 23 Apr 1998 08:55:54 -0700
Message-Id: <353E1EF9.21F9@gte.net>
Date: Wed, 22 Apr 1998 11:46:49 -0500
From: MJE <evans@gte.net>
Reply-To: evans@gte.net
Organization: None
X-Mailer: Mozilla 3.01 (Win95; I)
Mime-Version: 1.0
To: jeffery@cs.utsa.edu
Cc: icon-group@optima.CS.Arizona.EDU, evans@gte.net
Subject: Re: Is this language dead?
References: <6gir3d$d0d@bgtnsc02.worldnet.att.net>, <slrn6j2hok.6li.davecook@mozart.cts.com>, <6hhqi6$2p9@bgtnsc01.worldnet.att.net> <6hjj4m$inc@ringer.cs.utsa.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Content-Length: 2173
>
> Sorry, you should use C if you need the full Win32 API. It is gigantic,
> ugly, and something we wouldn't want in the language. A Windows loadfunc()
> may get implemented and do what you want someday; I just need a DLL guru
> to come in and do it for us.
Three comments:
(1) Ugly barely begins to describe the Win32 API. What a royal mess it
is. I recently told a colleague that I was not happy with my C++ design
because it had to be tacked on to the side of our C++ framework.
"Well," he said, "the Windows SDK is tacked onto the side of the Windows
SDK."
(2) Stop talking about DLL's! You don't want to use DLL's as such, but
Component Object Model (COM) interfaces. COM objects solve all the
problems associated with DLL's. Good online articles are at
http://www.microsoft.com/oledev/olecom/aboutole.htm
http://www.microsoft.com/oledev/olecom/com_modl.htm
and an excellent, basic book on the topic is described at
http://mspress.microsoft.com/prod/books/19.htm
This book is very well-written and a good starting point for the
uninitiated. It does not bog you down with the full weight of OLE2 or
ActiveX or ATL; it just describes COM. It holds you by the hand until
you understand.
Under COM, the main program does not need to know which physical file
holds the COM code with which it wants to link at run time. The
operating system handles those details invisibly.
The interesting aspect of COM is that it is already being ported to Unix
by Software AG and has already been ported to the Mac. COM is not
inherently a Windows-only API. Finally, Microsoft has done something
right. COM also maps closely to C++ although it is a
language-independent standard.
(3) A different way to approach the problem is to make Icon itself into
a COM object that is callable from external C++ code. I don't have many
concrete ideas on how to do it. You could have the interpreter swallow
a whole Icon program file as one COM interface, or have it accept
individual command lines as another.
I like the idea of having a COM Icon library that provides Icon-specific
services to external code, such as string scanning.
Best regards,
Mark Evans